Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> SQL Injection/Insertion, Jak zapobiec włamaniu na stronę.
Najki
post
Post #1





Grupa: Zarejestrowani
Postów: 190
Pomógł: 0
Dołączył: 12.02.2004
Skąd: Poznań

Ostrzeżenie: (0%)
-----


Pytania o streszczenie wątku, posty z "genialnymi" skryptami nadającymi się tylko na przedszkole i inne tego typu, będą bez ostrzeżenia usuwane przez moderatorów.
To mówiłem ja, Jarząbek... znaczy nospor dnia 2007-12-10
-------------------------------------------------------------------------------


SQL Injection (zwane też "SQL Insertion") to (rzekomo) najprostszy sposób włamu na stronę. Spowodowany jest on niepełnym sformułowaniem zapytań do MySQL.

Przykład. Dajemy na stronie możliwość edycji profilu. Zapytanie do SQL wygląda następująco:
  1. <?php
  2. $query = &#092;"update uzytkownicy set pole='$dane' where id='$id'\";
  3. ?>

Osoba włamująca się na stronę umieszcza całkiem prosty, odpowiedni ciąg znaków/poleceń w dowolnym polu edycji tego profilu, który wygląda np. tak (dla zmiany hasła użytkownika o dowolnie wybranym, przez atakującego numerze ID):
  1. <?php
  2. ', haslo='nowe_haslo' WHERE id = '1
  3. ?>


W taki oto prosty sposób, osoba atakująca zmieniła hasło użytkownikowi o ID=1 (zazwyczaj administrator). W podobny sposób można również wyciągnąć dowolne dane z tabeli SQL.

W każdym razie. Poszperałem, pomyślałem i zebrałem wszystko do kupy. Zamieszczam to tutaj razem, oraz proszę o rozbudowanie tego topica, gdyż nie znalazłem na tym forum więcej informacji o "SQL Injection".

Oto co możemy dokonać:
1. Możemy sformułować nasze zapytanie do SQL tak:
  1. <?php
  2. $query = 'update `uzytkownicy` set `pole`=\"'.$dane.'\" where `id`=\"'.$id.'\";';
  3. ?>

2. Przy wstawianiu numerów ID do zapytań należy stosować tzw. rzutowanie typów:
  1. <?php
  2. $id = (int)$_GET['id'];
  3. // lub
  4. $id = intval($_GET['id']);
  5. ?>

3. Przy wstawianiu tekstów, należy wyciąć niebezpieczne znaki przy pomocy funkcji:
  1. <?php
  2. $string = mysql_real_escape_string($_POST['string']); // PHP5
  3.  
  4. $string = mysql_escape_string($_POST['string']); /* lub */ $string = addslashes($_POST['string']); // PHP4
  5. ?>


Może nie ma tego dużo, ale jest to już jakaś podstawa do zabezpieczenia strony/skryptu przed prostym i niezwykle niebezpiecznym, SQL Injection. Proszę osoby obeznane w tym temacie, aby dopisały tu własne propozycje metod zabezpieczenia się przed tym atakiem.

Ten post edytował Najki 14.02.2008, 10:04:12
Go to the top of the page
+Quote Post
22 Stron V  « < 12 13 14 15 16 > »   
Start new topic
Odpowiedzi (260 - 279)
aio
post
Post #261





Grupa: Zarejestrowani
Postów: 28
Pomógł: 4
Dołączył: 13.11.2009

Ostrzeżenie: (0%)
-----


1 obraz > 1000 słów
  1. function _P($sql) { return mysql_real_escape_string(get_magic_quotes_gpc()?stripslashes($sql):$sql); }

Przykładowe użycie:
  1. $query = "SELECT * FROM `login` WHERE `login`='"._P($_POST['login'])."'";

jak ktoś to shakuje to wysyłam mu Moet!
Go to the top of the page
+Quote Post
pyro
post
Post #262





Grupa: Zarejestrowani
Postów: 2 148
Pomógł: 230
Dołączył: 26.03.2008

Ostrzeżenie: (0%)
-----


  1. function _P($sql) { return mysql_real_escape_string(get_magic_quotes_gpc()?stripslashes($sql):$sql); }
  2. mysql_query('SELECT id,name FROM videos WHERE `video_id` = '._P($_GET['video_id']));


Kod
http://strona.pl?video_id=-1 UNION SELECT username,password FROM users LIMIT 1


Wyślij mi Moet, cokolwiek to jest.

Ten post edytował pyro 13.02.2010, 12:30:17
Go to the top of the page
+Quote Post
wiiir
post
Post #263





Grupa: Zarejestrowani
Postów: 260
Pomógł: 34
Dołączył: 22.02.2010

Ostrzeżenie: (0%)
-----


Cytat(pyro @ 13.02.2010, 12:28:23 ) *
  1. function _P($sql) { return mysql_real_escape_string(get_magic_quotes_gpc()?stripslashes($sql):$sql); }
  2. mysql_query('SELECT id,name FROM videos WHERE `video_id` = '._P($_GET['video_id']));


Kod
http://strona.pl?video_id=-1 UNION SELECT username,password FROM users LIMIT 1


Wyślij mi Moet, cokolwiek to jest.



podwarunkiem ze tablea users istnieje o polach username, password
(IMG:style_emoticons/default/smile.gif)

a co bys zrobils jak by sie okazalo ze hasla trzymane sa w innej bazie o glupiej nazwie z glupia kolmna?(IMG:style_emoticons/default/questionmark.gif) ?
wiec w obrebie polaczenia tego zapytania wyzej byc nic nie uzyskal..

a przy logowaniu leci POST a nie GET plus ta funkcja co pisal kolega do filtrowania danych
Go to the top of the page
+Quote Post
nospor
post
Post #264





Grupa: Moderatorzy
Postów: 36 557
Pomógł: 6315
Dołączył: 27.12.2004




Cytat
podwarunkiem ze tablea users istnieje o polach username, password
Jakie istnieją tabele i jakie mają kolumny też bez problemu dzieki tej dziurze można wykryc... wystarczy ze ktos umozliwia dziure i juz jestesmy w domu.
Go to the top of the page
+Quote Post
kilas88
post
Post #265





Grupa: Zarejestrowani
Postów: 305
Pomógł: 25
Dołączył: 27.01.2007

Ostrzeżenie: (0%)
-----


Cytat(wiiir @ 24.02.2010, 14:37:34 ) *
podwarunkiem ze tablea users istnieje o polach username, password
(IMG:style_emoticons/default/smile.gif)

a co bys zrobils jak by sie okazalo ze hasla trzymane sa w innej bazie o glupiej nazwie z glupia kolmna? (IMG:style_emoticons/default/questionmark.gif) ?
wiec w obrebie polaczenia tego zapytania wyzej byc nic nie uzyskal..


Skoro dziurawy skrypt otrzymuje dane to i haker dostałby te dane. Nie musi znać dokładnej struktury tabeli - może działać metodą prób i błędów. To zadanie można też zautomatyzować i myślę, że osoby bawiące się w tych tematach takowe już posiadają (IMG:style_emoticons/default/smile.gif)
Go to the top of the page
+Quote Post
wiiir
post
Post #266





Grupa: Zarejestrowani
Postów: 260
Pomógł: 34
Dołączył: 22.02.2010

Ostrzeżenie: (0%)
-----


Dodajac replace na UNION + kilka innych , ustalenie jakie tabele i kolumny jest raczej bardzo trudne
do tego mozna zrobic tak jak mowilem zeby trzymac hasla i uzytkownikow i pare innych poufnych danych w innej bazie to daje tyle ze w obrebie poruszanaia sie po serwisie operujemy tylko na danych wyswietlanych a nie poufnych... chyba ze mozna to obejsc ja nie wiem jak.. wydaje mi sie byc to dobrym pomyslem

Oczywiscie ze dla hakera nie ma rzeczy nie mozliwych, tylko ze wtedy nie ma tak latwo
Nie jestem expertem.. sam chce sie w miare dobrze przed tym zabiezpieczyc

Ten post edytował wiiir 24.02.2010, 15:00:39
Go to the top of the page
+Quote Post
pyro
post
Post #267





Grupa: Zarejestrowani
Postów: 2 148
Pomógł: 230
Dołączył: 26.03.2008

Ostrzeżenie: (0%)
-----


Cytat(wiiir @ 24.02.2010, 14:37:34 ) *
podwarunkiem ze tablea users istnieje o polach username, password

a przy logowaniu leci POST a nie GET plus ta funkcja co pisal kolega do filtrowania danych


Drogi @wiiir, podane tabele to były najzwyklejsze przykłady, mogłem równie dobrze też napisać tabele asfjaiofjadfo oraz asjfhkjasdkjas. Też byś wtedy napisał `wątpię, żeby jakiś serwis miał pola i tabele o takich nazwach`?

A czy według Ciebie SQL Injection może mieć miejsce tylko w skrypcie logowania? Jak taki błąd ma miejsce na przykład w newsach na tej samej stronie to mogę tak samo z tego miejsca wyciągnąć nazwy użytkowników i ich hasła (IMG:style_emoticons/default/smile.gif)

Cytat(wiiir)
wiec w obrebie polaczenia tego zapytania wyzej byc nic nie uzyskal..


Nie warto się zastanawiać, co mógłby zrobić potencjalny włamywacz w związku z istniejącym błędem. Ważne, żeby zadbać o to, żeby go nie było.
Go to the top of the page
+Quote Post
wiiir
post
Post #268





Grupa: Zarejestrowani
Postów: 260
Pomógł: 34
Dołączył: 22.02.2010

Ostrzeżenie: (0%)
-----


jakis bys napisal ze masz nazwy takich tabl i kolumn to bym sie nie zdzwil bo ja czesto stosuje cos takiego.. moze nie taki random jak podales.. albo cos podobnego, wiem ze odpowiesz ze jest to do ustalenia.. .ale osoba ktora pisze sobie taki skrypty zazwyczaj stosuje standardowe nazwy tabel ktore znajdzie w tutakach, a hakerowi to jest nareke, inne nazwy rozne prefixy itd daja tyle ze juz trzeba cos zrobic wiecej ..

Wiadomo ze w pierwszej kolejnosci nalezy zabiezpieczyc skrypt pod w zgledem otrzymywanych danych.. ale wiadomo ze o czyms mozna zapomniec.. a sam id uzytkownika tez duzo nie daje takie dane mozna z cockie zebrac, a zeby odnalesc haslo musisz zainicjowac nowe polaczenie do drugiej bazy, zeby to zrobic trzeba byc juz naprawde niezlym gosciem

To o logowaniu to tak na marginesie bo tam jest popelniany 1 blad

Temat ten mozna by cignac w nieskonczonosc a i tak znalazby sie haker ktory by znalazl dziurke (IMG:style_emoticons/default/smile.gif)
Go to the top of the page
+Quote Post
pyro
post
Post #269





Grupa: Zarejestrowani
Postów: 2 148
Pomógł: 230
Dołączył: 26.03.2008

Ostrzeżenie: (0%)
-----


Cytat(wiiir @ 24.02.2010, 15:51:48 ) *
jakis bys napisal ze masz nazwy takich tabl i kolumn to bym sie nie zdzwil bo ja czesto stosuje cos takiego.. moze nie taki random jak podales.. albo cos podobnego, wiem ze odpowiesz ze jest to do ustalenia.. .ale osoba ktora pisze sobie taki skrypty zazwyczaj stosuje standardowe nazwy tabel ktore znajdzie w tutakach, a hakerowi to jest nareke, inne nazwy rozne prefixy itd daja tyle ze juz trzeba cos zrobic wiecej ..


trudniejsze czy nie, to generalnie kwestia czasu, po prostu nie można sobie pozwolić na to, żeby taka miała miejsce

Cytat(wiiir @ 24.02.2010, 15:51:48 ) *
Wiadomo ze w pierwszej kolejnosci nalezy zabiezpieczyc skrypt pod w zgledem otrzymywanych danych.. ale wiadomo ze o czyms mozna zapomniec.. a sam id uzytkownika tez duzo nie daje takie dane mozna z cockie zebrac, a zeby odnalesc haslo musisz zainicjowac nowe polaczenie do drugiej bazy, zeby to zrobic trzeba byc juz naprawde niezlym gosciem


Pisze się w cookies. No, chyba że sugerujesz, że ludzie przetrzymują nazwy użytkowników w kutaskach (IMG:style_emoticons/default/tongue.gif) . Niestety takie rozwiązanie mogłoby być uciążliwe dla damskiej części użytkowników.

Bardzo rzadko id użytkownika przetrzymuje się w cookies. A żeby nawet go wyciągnąc stamtąd, trzeba by było znaleźć inną lukę (XSS).

Cytat(wiiir @ 24.02.2010, 15:51:48 ) *
To o logowaniu to tak na marginesie bo tam jest popelniany 1 blad


No to równie dobrze mogłeś napisać coś o hardware, bo to również wiąże się z komputerami, na których się pisze kod.

Cytat(wiiir @ 24.02.2010, 15:51:48 ) *
Temat ten mozna by cignac w nieskonczonosc a i tak znalazby sie haker ktory by znalazl dziurke (IMG:style_emoticons/default/smile.gif)


To zdanie jest również (według mnie) fałszywe. Można pisać tak, żeby nie popełniać błędów.
Go to the top of the page
+Quote Post
wiiir
post
Post #270





Grupa: Zarejestrowani
Postów: 260
Pomógł: 34
Dołączył: 22.02.2010

Ostrzeżenie: (0%)
-----


Cytat(pyro @ 24.02.2010, 16:15:38 ) *
trudniejsze czy nie, to generalnie kwestia czasu, po prostu nie można sobie pozwolić na to, żeby taka miała miejsce

czasami wlasnie ten czas dziala na twoja korzysc oznacza to im dluzej ktos prubuje wlamac tym masz lepsze zabezpieczenia

Cytat(pyro @ 24.02.2010, 16:15:38 ) *
Pisze się w cookies. No, chyba że sugerujesz, że ludzie przetrzymują nazwy użytkowników w kutaskach (IMG:style_emoticons/default/tongue.gif) . Niestety takie rozwiązanie mogłoby być uciążliwe dla damskiej części użytkowników.

Bardzo rzadko id użytkownika przetrzymuje się w cookies. A żeby nawet go wyciągnąc stamtąd, trzeba by było znaleźć inną lukę (XSS).

Moze sie i pisze ale widzialem ludzi ktorzy trzymaja hasla i w sesji jak i w cookie


Cytat(pyro @ 24.02.2010, 16:15:38 ) *
To zdanie jest również (według mnie) fałszywe. Można pisać tak, żeby nie popełniać błędów.

Nie jestes w stanie tak napisac kodu zeby nie popelnic bledu. Inaczej nie bylo by wlamow do najwikszych instytucji Polsce i na swiecie.
Go to the top of the page
+Quote Post
Crozin
post
Post #271





Grupa: Zarejestrowani
Postów: 6 476
Pomógł: 1306
Dołączył: 6.08.2006
Skąd: Kraków

Ostrzeżenie: (0%)
-----


Cytat
Nie jestes w stanie tak napisac kodu zeby nie popelnic bledu.
Jest, jest. Na świecie powstaje cała masa bezpiecznego (w pełni) kodu. Problemy pojawiają się przy pisaniu skomplikowanych programów/skryptów jak i przy wykorzystywaniu oprogramowania firm trzecich - co jest właściwie... nieuniknione.

Ale napisanie programu/skryptu do którego nie da się włamać bezpośrednio jest możliwe.

Ten post edytował Crozin 24.02.2010, 17:22:29
Go to the top of the page
+Quote Post
pyro
post
Post #272





Grupa: Zarejestrowani
Postów: 2 148
Pomógł: 230
Dołączył: 26.03.2008

Ostrzeżenie: (0%)
-----


Cytat(wiiir @ 24.02.2010, 16:47:36 ) *
czasami wlasnie ten czas dziala na twoja korzysc oznacza to im dluzej ktos prubuje wlamac tym masz lepsze zabezpieczenia


Niestety ten czas niewiele działa na korzyść, bo prędzej czy później minie (IMG:style_emoticons/default/winksmiley.jpg) Lepsze zabezpieczenia? Na litość boską, to wcale nie znaczy o lepszych zabezpieczeniach.

Cytat(wiiir @ 24.02.2010, 16:47:36 ) *
Nie jestes w stanie tak napisac kodu zeby nie popelnic bledu. Inaczej nie bylo by wlamow do najwikszych instytucji Polsce i na swiecie.


Zaryzykuje to stwierdzenie, ale jestem. A już przynajmniej od strony SQL Injection, o którym jest temat.

Ten post edytował pyro 24.02.2010, 23:13:45
Go to the top of the page
+Quote Post
wiiir
post
Post #273





Grupa: Zarejestrowani
Postów: 260
Pomógł: 34
Dołączył: 22.02.2010

Ostrzeżenie: (0%)
-----


Cytat(pyro @ 24.02.2010, 23:11:24 ) *
Niestety ten czas niewiele działa na korzyść, bo prędzej czy później minie (IMG:style_emoticons/default/winksmiley.jpg)

Do tego mnie nie przekonasz, porownanie np: bo przeciez to ze nie miales wypadku nie oznacza ze kiedys i tak bedziesz "musial" miec, no i wcale nie musisz a mozesz
tak samo z wlamem moze byc taka sytuacja ze jest dziura, ale koles probuje probuje i nic az wkoncu daje sobie spokuj..

Ucieklismy od temau ups (IMG:style_emoticons/default/tongue.gif)

Tak ogolnie patrzac na twoje stwierdzenie zrob nam dekalog dobrego zabezpieczenia SQL Injection ktore stosujesz (IMG:style_emoticons/default/smile.gif)

Ten post edytował wiiir 25.02.2010, 08:57:16
Go to the top of the page
+Quote Post
kilas88
post
Post #274





Grupa: Zarejestrowani
Postów: 305
Pomógł: 25
Dołączył: 27.01.2007

Ostrzeżenie: (0%)
-----


Cytat(wiiir @ 25.02.2010, 08:34:14 ) *
Tak ogolnie patrzac na twoje stwierdzenie zrob nam dekalog dobrego zabezpieczenia SQL Injection ktore stosujesz (IMG:style_emoticons/default/smile.gif)


http://php.net/manual/en/pdo.prepare.php


To powinno załatwić sprawę.

Go to the top of the page
+Quote Post
ucho
post
Post #275





Grupa: Zarejestrowani
Postów: 300
Pomógł: 32
Dołączył: 31.07.2006

Ostrzeżenie: (0%)
-----


Cytat(wiiir @ 24.02.2010, 14:57:42 ) *
Dodajac replace na UNION + kilka innych , ustalenie jakie tabele i kolumny jest raczej bardzo trudne

(IMG:style_emoticons/default/sciana.gif)
Podałbym przykład jak ominąć takie pseudozabezpieczenie w postacie replace ale podejrzewam, że zacząłbyś po prostu dokładać kolejne warunki brnąc w ślepą uliczkę. Nazwy tabel i pól można pobierać zwykłymi zapytaniami, przecież większość ORMów właśnie to robi nie mówiąc o np. phpMyAdminie.
Go to the top of the page
+Quote Post
pyro
post
Post #276





Grupa: Zarejestrowani
Postów: 2 148
Pomógł: 230
Dołączył: 26.03.2008

Ostrzeżenie: (0%)
-----


Cytat(wiiir @ 24.02.2010, 14:57:42 ) *
Dodajac replace na UNION + kilka innych


Oczywiście... w JPortalu już czegoś takiego próbowali i miałem dzięki temu dużo "zabawy" (IMG:style_emoticons/default/smile.gif) .
Go to the top of the page
+Quote Post
aio
post
Post #277





Grupa: Zarejestrowani
Postów: 28
Pomógł: 4
Dołączył: 13.11.2009

Ostrzeżenie: (0%)
-----


@pyro
szampan się nie należy! zmodyfikowałeś mój kod, tworząc lukę ( zlikwidowałeś cudzysłów ), więc shakowałeś swój kod, mój pozostał nietknięty (IMG:style_emoticons/default/winksmiley.jpg)

Kto następny?

Go to the top of the page
+Quote Post
Crozin
post
Post #278





Grupa: Zarejestrowani
Postów: 6 476
Pomógł: 1306
Dołączył: 6.08.2006
Skąd: Kraków

Ostrzeżenie: (0%)
-----


@aio: Traktowanie liczb jako tekstu (tj.: id = "123", zamiast normalnego id = 123) jest brzydkim/złym zwyczajem - chociaż w tym przypadku (o ile wszędzie wszystkie dane traktowałbyś jako tekst) ratuje Cię to przed potencjalnym atakiem.
Go to the top of the page
+Quote Post
pyro
post
Post #279





Grupa: Zarejestrowani
Postów: 2 148
Pomógł: 230
Dołączył: 26.03.2008

Ostrzeżenie: (0%)
-----


Cytat(aio @ 1.03.2010, 23:04:44 ) *
@pyro
szampan się nie należy! zmodyfikowałeś mój kod, tworząc lukę ( zlikwidowałeś cudzysłów ), więc shakowałeś swój kod, mój pozostał nietknięty (IMG:style_emoticons/default/winksmiley.jpg)

Kto następny?


Ale co Ty w takim razie chciałeś zrobić? Pokazać jak napisałeś dwie linijki kodu, których nie da się tknąć? Zobacz o czym jest wątek. Jest on o zabezpieczaniu przed SQL Injection/Insertion, a nie o zabezpieczaniu jednego, konkretnego, prostego zapytania. Z Twojego posta można było jedynie wywnioskować, że odkryłeś "cudowną funkcję", która zabezpiecza przed SQL Injection. Niestety NIEWIELE ona zabezpiecza i ktoś posługując się nią prawdopodobnie miałby luki w swoim serwisie/stronie. To co napisałeś nie rozwiązuje nawet w połowie zagrożenia SQL Injection. Jestem niemal pewien, że nawet jakbyś teraz rozbudował te "logowanie" o parę linijek kodu do rejestracji, to już by była podatna na atak.

A wino mi się w takim razie należy chociażby za Twojego nic nie wnoszącego do tematu posta (IMG:style_emoticons/default/tongue.gif)

Ten post edytował pyro 2.03.2010, 00:13:28
Go to the top of the page
+Quote Post
aio
post
Post #280





Grupa: Zarejestrowani
Postów: 28
Pomógł: 4
Dołączył: 13.11.2009

Ostrzeżenie: (0%)
-----


Cytat(pyro @ 2.03.2010, 00:12:13 ) *
Ale co Ty w takim razie chciałeś zrobić? Pokazać jak napisałeś dwie linijki kodu, których nie da się tknąć? Zobacz o czym jest wątek. Jest on o zabezpieczaniu przed SQL Injection/Insertion, a nie o zabezpieczaniu jednego, konkretnego, prostego zapytania. Z Twojego posta można było jedynie wywnioskować, że odkryłeś "cudowną funkcję", która zabezpiecza przed SQL Injection. Niestety NIEWIELE ona zabezpiecza i ktoś posługując się nią prawdopodobnie miałby luki w swoim serwisie/stronie. To co napisałeś nie rozwiązuje nawet w połowie zagrożenia SQL Injection. Jestem niemal pewien, że nawet jakbyś teraz rozbudował te "logowanie" o parę linijek kodu do rejestracji, to już by była podatna na atak.

A wino mi się w takim razie należy chociażby za Twojego nic nie wnoszącego do tematu posta (IMG:style_emoticons/default/tongue.gif)


Chyba się nie rozumiemy. Nie chodziło mi o atak literacki mnie na forum! Na serwerze jako haker, jesteś w stanie tknąć kod? Nie! Hakujesz wejściem poprzez REQUEST! Zrozumiałem że o tym mowa w tym wątku, nieprawdaż? Utwórz taki REQUEST (_GET), żeby shakować mój kod. Nie chcę być niegrzeczny ale czy nie mam przypadkiem racji? Czy uważasz, że Twój post cokolwiek wniósł?

Pozdrawiam

Cytat(Crozin @ 1.03.2010, 23:33:47 ) *
@aio: Traktowanie liczb jako tekstu (tj.: id = "123", zamiast normalnego id = 123) jest brzydkim/złym zwyczajem - chociaż w tym przypadku (o ile wszędzie wszystkie dane traktowałbyś jako tekst) ratuje Cię to przed potencjalnym atakiem.


Do enginu mysqla wysyłasz String. 123 przy parsowaniu jest konwertowane na Number. Tak samo '123' będzie konwertowane do Number, z tą zaletą że poprzez szybszy natywny engine mysql i tylko JEDEN raz, a nie dodatkowe linijki kodu php z większym ryzykiem popełnienia błędu. Jakaż jest przewaga (np wydajności) skryptu z uprzednią konwersją na Number, skoro trzeba przewidzieć i dopisać ochronę w innych przypadkach?

Czy zatem jest coś brzydszego od konwertowania po kilka razy tej samej wartości w kółko na dziesięć sposobów rzekomo utrudniających atak? (IMG:style_emoticons/default/winksmiley.jpg) . Że typ String jest brzydki jako taki? To jest ten argument?
I najważniejsze, bo może nie doczytałem czegoś, ten wątek jest o utrudnianiu czy ułatwianiu rozwiązania zagadnienia? Np. kolega wyżej zamiast dokonać włamu, opracował lukę i dumnie obwieścił, że udowodnił, że się umie włamać - SIC!

PS. Wiem, że wyżej gdzieś ktoś pisał, że jak podamy liczbę jako String, to ma wpływ na performance, ale chyba się zgodzimy wszyscy, że nie dotyczy to tego przypadku?

Pozdrawiam
Go to the top of the page
+Quote Post

22 Stron V  « < 12 13 14 15 16 > » 
Reply to this topicStart new topic
2 Użytkowników czyta ten temat (2 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Aktualny czas: 24.08.2025 - 11:02